iOS开发文档翻译：苹果通知中心服务,The Apple Notification Center Service

苹果通知中心服务是一个主要服务（primary service），它的蓝牙服务（service）宇宙唯一标识符（UUID）是7905F431-B5CE-4E99-A40F-4B1E122D00D0。

在一个通知提供者（NP）上，最多只能有一个苹果通知中心服务（ANCS）实例。iOS 本身的某些特点导致了无法确保苹果通知中心服务是一直存在的。因此，通知消费者（NC）应当寻找并且订阅到通用属性档案（GATT）服务的服务已改变（Service Changed）特性（characteristic），以便监测到任何时候可能发生的ANCS 被发布及取消发布事件。

在一般情况下，ANCS 会暴露出三个特性：

• •. 通知源（Notification Source）： 宇宙唯一标识符 9FBF120D-6301-42D9-8C58-25E699A21DBD (可通知)

• •. 控制点（Control Point）： 宇宙唯一标识符 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (可写，并带有回应)

• •. 数据源（Data Source）： 宇宙唯一标识符 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (可通知)

对通知源特性的支持是必需的，但是对控制点和数据源特性的支持是可选的。

注意：除了以上列出的三个特性之外，苹果通知中心服务可能还包含有更多其它的特性。不过呢，一个通知消费者可以忽略任何它不认识的特性。

获取通知属性命令，使得一个通知消费者可获取指定iOS 通知的属性。获取通知属性命令的格式在图 2-3 中说明。

图 2-3 获取通知属性命令的格式

一个 获取通知属性 命令包含以下信息：

• •. CommandID: 应当设置为0 (CommandIDGetNotificationAttributes)。

• •. NotificationUID: 32位的数字值，代表着客户端想要获取其信息的iOS 通知的 唯一标识符 。

• •. AttributeIDs: 该通知消费者想要取回的属性的列表。某些属性可能需要在后面附加上一个16位的长度参数，指定该 通知消费者 想要为此属性取出的信息长度的最大字节数。

对于获取通知属性命令的回复内容的格式，在图 2-4 中说明。

对于获取通知属性命令的回复内容，包含以下信息：

• •. CommandID: 设置为0 (CommandIDGetNotificationAttributes)。

• •. NotificationUID: 32位的数字值，表示后续属性所对应的iOS 通知的 唯一标识符 。

• •. AttributeList: 由AttributeIDs/16位长度值（Length）/属性（Attribute） 三元组组成的列表。一个属性一定是以字符串来表示的，其长度的字节数在三元组中提供了，但这些字符串不是以空字符（NULL）结尾的。如果所请求的某个属性是空白的（empty）或者在该iOS 通知中是缺失的（missing），则其长度会是0 .

如果某个回应消息超过了预先协商的（negotiated）通用属性档案 最大传输单元（MTU）的大小，则通知提供者会将它分割成多个片断。这种情况下，通知消费者必须将每个片断拼接起来，形成一个完整的回应消息。当每个被请求的属性的三元组都完整地接收到了之后，该回应过程就完成了。

获取应用属性命令，使得一个通知消费者可以获取该通知提供者设备上安装的指定应用的属性。获取应用属性命令的格式在图 2-5 中说明。

一个获取应用属性命令包含以下信息：

• •. CommandID: 应当设置为1 (CommandIDGetAppAttributes)。

• •. AppIdentifier: 客户端想要获取其信息的应用的字符串标识。这个字符串必须是以空字符结尾的。

• •. AttributeIDs: 该通知消费者想要获取的属性列表。

对于获取应用属性命令的回应消息的格式，在图 2-6 中说明。

对获取应用属性命令的回应消息，包含以下信息：

• •. CommandID: 设置为1 (CommandIDGetAppAttributes)。

• •. AppIdentifier: 后续属性所对应的应用的字符串标识。这个字符串是以空字符结尾的。

• •. AttributeList: 一个由AttributeIDs/16位长度值/属性三元组组成的列表。一个属性一定是以字符串来表示的，其长度的字节数在三元组中提供了，但这些字符串不是以空字符（NULL）结尾的。如果所请求的某个属性是空白的（empty）或者对于该应用是缺失的（missing），则其长度会是0 .

就跟对于获取通知属性命令的回应一样，如果某个对于获取应用属性命令的回应消息超过了预先协商的（negotiated）通用属性档案 最大传输单元（MTU）的大小，则通知提供者会将它分割成多个片断。这种情况下，通知消费者必须将每个片断拼接起来，形成一个完整的回应消息。当每个被请求的属性的三元组都完整地接收到了之后，该回应过程就完成了。

强烈建议，通知消费者设备只在必要的时候才进行获取属性的动作，在可能的情况下，只有在用户作出操作要求获取信息时才做出这种动作。例如，如果某个通知消费者将当前的活跃iOS 通知显示在一个简单的列表中，并且在用户选中某项时才显示指定iOS 通知的细节，则，就可以以一种懒惰的策略来触发对于指定iOS 通知的属性的获取动作。

强烈建议，通知消费者对于它要处理的每一个应用标识都建立一个应用属性（App Attributes）缓存。建立这样一个缓存，使得通知消费者可以避免多次获取到重复的（same）不变的（immutable）应用属性—这样可以节约时间和电池寿命。

在向控制点特性写入命令时，通知消费者可能会收到以下与苹果通知中心服务相关的错误码：

• •. 未知命令 (0xA0): 通知提供者无法识别出这个commandID。

• •. 无效命令 (0xA1): 整个命令的内容格式不对。

• •. 无效参数 (0xA2): 其中的某个参数（例如，NotificationUID），在该通知提供者设备上找不到存在的对应对象。

如果通知提供者以一个错误码作出为回复，则，它不会在数据源特性上为对应的命令生成任何的通用属性档案通知。

图 2-8 通知属性获取过程的示例